(1) Field of the Invention
The present invention relates to the field of computer systems used for storage, retrieval, and processing of information. More specifically, the present invention relates to the field of parameter evaluation methods for tuning an information management system, e.g., a relational database management system.
(2) Prior Art
The migration of computing from mainframe systems to downsized client/server environments has created the need for a new generation of systems management technology for managing and monitoring the health of dispersed and diverse open systems. Once such technology includes performance tuning of computer controlled relational database management systems (RDBMS) to improve their data processing efficiency.
Computer implemented RDBMS are well known in the art. These database systems commonly employ data tables that contain columns and rows. Many database systems include different software objects that are organized in a hierarchical or entity relation (ER) topology in which parent objects and child objects are related to each other in certain predefined manners. In this topology, each software object contains one or more attributes and rules which are used to alter certain aspects of the database system (e.g., vary maximum and minimum ranges, constraints, resource usage, etc.) in order to tune the database system for different operational environments. The attributes can have attached rules and, in certain circumstances, the rules are used to evaluate the attributes or other system values. There are prior art approaches for using these object-attached rules for tuning a database environment to increase data throughput performance (the act of tuning can also be called "performance tuning" or "optimizing performance" or "performance optimization"). In accordance with these approaches, a database administrator (DBA) performance tunes the database system based on a set of input information which describes a particular target environment.
As an example of an attribute, a "parameter" is a type of attribute and is a modifiable value that can be changed in order to influence the manner in which a database system responds and the manner in which database resources are allocated within a database system. FIG. 1 illustrates an exemplary hierarchical topology of instance parameters A-K. An instance parameter contains a set of rules defining the respective manner in which the parameter is to be evaluated and the dataset on which the parameter is dependent, if any. In order to provide an effective RDBMS environment (database environment), the parameters require tuning for a particular database program or "instance." In general, parameters influence the amount and manner in which the following computer resources are used for a given instance: CPU processing; input/output (I/O) resources; memory resources; and contention regarding the number of locks within a system. It is expected that, by performance tuning, data flow bottlenecks regarding these database resources can be reduced.
During the database performance optimization process, object-attached rules execute in sequences and potentially form conclusions regarding particular aspects of the database system that are tunable for a given environment. Optimization conclusions are based on three groups of information: 1) user-supplied performance data that is external to the rule; 2) embedded knowledge of database performance behavior within a rule; and 3) database performance knowledge constraints within a rule. Of the above three groups of information, the first group is traditionally unknown until the rule is ready to execute. The second group is hardcoded within the rule (e.g., using fixed program instructions that are not user-modifiable), and the third group is either hardcoded within the rule or loaded at run-time from a fixed external file in computer memory. Therefore, in the past, when a rule is executed, the output is based partly on variable user-data and non-variable fixed knowledge.
A problem arises when the non-variable fixed knowledge (e.g., of the second and third groups) needs to change dynamically based on some condition of the first group's data or some other external influence, e.g., to allow the optimization process to dynamically tune the database system for a particular environment. For the second group (the embedded knowledge of data performance behavior) multiple rules need to be written to handle all possible cases. For the third group, the fixed constraints need to be edited in the external file, or the values need to be changed dynamically within the rule. For the second and third groups, the step of modifying behavior still requires some prior knowledge of the possible changes. For example, given that a rule must handle 10 different database environments, there must be 10 versions of the rule. When modifying a third group constraint, the rule must know when the value is good for one type of decision but not good for another.
In the prior art, one approach for dynamically altering a rule provides a file of fixed attribute values which can be changed (thus altering the behavior of the rules which use the values) to allow the user to describe differences in the database environment. However, under this first approach, when a particular attribute in this file is altered, the new value is applied to all objects for all cases. Therefore, the first approach does not allow the use to discriminate between objects that share a common attribute value. For instance, during a tuning session it is not possible under the first approach for one instance (e.g., instance A) to have one value for parameter A and for another instance (e.g., instance B) to have another value for parameter A. Moreover, during a tuning session, assuming a schema has table A and table B, it is not possible to offer one type of index constraint for table A while offering another type of index constraint for table B. This result is disadvantageous because there are many cases where it would be desirable to discriminate between table A and table B during tuning. For example, table A might only be used for data retrieval (e.g., outputs only), while table B might only be used for transactions (e.g., input/output). Therefore, this first prior art approach of "tailoring" object attributes for a given tuning session is disadvantageous because once an attribute value is altered, it becomes all encompassing and uniformly applied to all objects for all database environments.
A second prior art approach for dynamically altering a rule is to particularly modify rules at the object level using fixed parameters to incorporate the needed information. While this second approach allows the user to discretely modify rules at the object level, it is disadvantageous for several reasons. Under one technique, if the user is allowed to provide fixed attributes for rules located within very high hierarchical object levels (e.g., near the root level), then the changes will influence a large number of lower objects. In this case, much like the first approach, the user is unable to make discrete object changes for the objects located in the lower hierarchical levels. Moreover, under a second technique, if the user is allowed to provide fixed parameters for rules located in low hierarchical levels, then all objects within the low hierarchical levels need to be modified individually. In some instances, there can be over 600 objects that utilize a particular modifiable attribute within a given low hierarchical level. Under this second technique, each of these objects would need to be individually modified in order to effect changes applicable for the modifiable attribute. Therefore, both of the above techniques of the second approach are undesirable because: 1) under the first technique, the modifications are too encompassing; and 2) under the second technique, the required modifications are too numerous to be practical.
Accordingly, what is desired is a tuning system that allows a user to readily define differences in system environments so that the database system can be dynamically performed tuned for these environments. What is needed, more particularly, is a system that allows a user to modify object attributes at the object level (thus particularly defining differences in system environments at the object level) without having each user modification apply to all objects uniformly. What is further desired is a mechanism that allows object-level rule modifications (e.g., that are tailored for a particular environment) within objects of a particular hierarchical level that does not also require custom modifications be made to a inordinate number of objects of that particular hierarchical level. As further described herein, the present invention provides these advantageous results.